Device navigational maps for connected devices

ABSTRACT

Described herein is a method for creating and utilizing device navigational maps. The device navigational maps are modeled using directed graphs that contain detailed information of all components on the connected devices. An application systematically scans through the entire connected device and builds a detailed data model of the connected device, which is used as the navigational map.

TECHNICAL FIELD

This application is related to connected devices and, in particular, tocreation and utilization of device navigational maps for the connecteddevices.

SUMMARY OF THE INVENTION

Described herein is a method for creating and utilizing devicenavigational maps. The device navigational maps are modeled usingdirected graphs that contain detailed information of all elements onconnected devices. The term connected device may refer to, but is notlimited to, mobile devices, smartphones, personal digital assistants(PDAs), smart televisions, tablets, set-top boxes, and the like.

The device navigational maps may be used for building connected devicesimulators, educational tutorials, interactive guidance systems forconnected devices, capturing the user actions on the connected deviceswhen assistance is needed, creating analytics on usage of connecteddevice components and capturing and analyzing user behavior on theconnected devices. Device navigational maps may also be used to creatediagnostic fixes on the connected device for commonly faced connecteddevice issues.

A navigational map is a hierarchical graphical representation of aspecific area or the entire software running on the connected devicealong with the actions that may need to be performed in order tonavigate within a structure or architecture of the connected device.Maps stand out as an efficient, effective method of recording, storing,and transferring information.

One of the primary benefits of device navigational maps is the abilityto utilize them in creating comprehensive interactive guidance tools forconnected devices as described in U.S. patent application Ser. No.14/042,846, filed Oct. 1, 2013, and entitled “METHOD AND APPARATUS FORINTERACTIVE MOBILE DEVICE GUIDANCE”, which is herein incorporated byreference. The interactive guidance system has the capability toinstruct and guide end users of connected devices to navigate throughits various functions and configurations.

Another benefit of the device navigational maps is the ability to usethem in creating connected device tutorials dynamically. The movetowards improved customer care and guidance post connected device saleunderscores a growing need to educate customers of the new features ofconnected devices. The carriers and connected device manufacturersutilize this as a way to build customer loyalty, lower the turnover andproduct return rate, sell additional accessories, and stand out in a seaof retail options. These services are more important than ever as themarket evolves past early adopters and technology enthusiasts. Since thenavigation maps have information about all the components of theconnected device and information on how to navigate to differentcomponents and software configurations, connected device softwarerelated tutorials can be developed dynamically on the connected devicewhere the navigational maps are installed.

Another benefit of the device navigational map is the ability to usethem in creating connected device simulators. A connected devicesimulator allows a user to verify the functionality of device operatingsystems and mobile applications across different mobile platforms, suchas iPhone®, iPad®, Android® and BlackBerry®, (each term being atrademark of Apple, Google and Blackberry, respectively), withoutactually having the connected devices in hand. Connected devicesimulators can help both the device users and the customer serviceagents to become familiar with the device user interface, device systemconfiguration, and most common applications running on the connecteddevice without having a physical device. By providing a search enginethat works in conjunction with the navigation maps and input keywords,an agent can easily find and navigate to any system configurationscreens, application settings and similar information. A comprehensivemap of the connected device layout and structure helps in creatingdevice simulators of varying complexities with ease.

Another benefit of the device navigational maps is the ability tocapture and analyze customer usage, behavior and preferences on aconnected device in order to develop detailed analytics that will helpin further improving the connected devices. This capability could alsobe extended to generate analytics on the navigation patterns and userexperience latency of any mobile application. This is particularlyuseful to application developers in improving their overall applicationuser experience. During the last decade, connected devices have gainedpopularity all over the world and this popularity continues to grow. Thekey differences between connected devices and earlier connected phonesare full-featured internet access and easy availability of newapplications through modern operating system (OS) platforms and appstores. Understanding the application and service usage of customers isan important step in designing applications and systems on which theapplications run. The device navigational maps provide good datacapturing methods that can be used for archiving and analyzing usagepatterns.

Other objectives and advantages of this invention will become apparentfrom the following description taken in conjunction with theaccompanying drawings wherein are set forth, by way of illustration andexample, certain embodiments of this invention. The drawings constitutea part of this specification and include exemplary embodiments of thepresent invention and illustrate various objects and features thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 describes the system architecture of the device navigation systemwith the navigation map service running within a connected device;

FIG. 1a describes the system architecture of the device navigationsystem with the navigation map service running on an external personalcomputer (PC) or server;

FIG. 1b describes the navigation map service in detail;

FIG. 2 describes the device navigation system with navigation mapbuilder hosted in an external system;

FIG. 3 describes the device navigation system with the navigation mapbuilder hosted within a connected device on which the navigation map isbuilt;

FIG. 4 shows an exemplary overview of a device navigational map;

FIGS. 5a-b describe a detailed call flow used in building a navigationmap graph;

FIG. 6 describes a detailed call flow for the Explore new screen subprocess;

FIG. 7 shows a closer view of a device navigational map in a graphicalrepresentation;

FIG. 8 shows an exemplary structure of the navigational graph;

FIG. 9 shows a sample image of a vertex within a navigational graph;

FIG. 10 shows an exemplary structure of a vertex within a navigationalgraph;

FIG. 11 shows a sample image of an edge with a navigational graph;

FIG. 12 shows an exemplary structure of an edge within a navigationalgraph;

FIG. 13 shows a sample image of a device simulator built using, a devicenavigational map; and

FIG. 14 describes the call flow for utilizing navigational maps, ininteractive device navigation.

DETAILED DESCRIPTION

Described herein is a method for creating and utilizing devicenavigational maps for connected devices. An application systematicallyscans through the entire connected device and builds a detailed datamodel of the connected device, which is used as a navigational map (NM).A navigational map is a directional graph containing details of all theelements on the connected device and meta information associated withthose elements. The term connected device may refer to, but is notlimited to, mobile devices, smartphones, personal digital assistants(PDAs), smart televisions, tablets, set-top boxes, and the like.

FIG. 1 describes the system architecture of the device navigation systemin detail. The device navigation system contains the following maincomponents: a Navigation Map [NM] Web Server 100, Navigation Map Service102, Database for device maps/navigation map repository 103 andNavigation Map Builder 105. The following additional components are usedin utilizing the device navigation maps: Simulator 104 and theapplication which is hosted within a remote device 107 for the purposeof providing navigation service. All components of the systemcommunicate with each other over the air though an internet connection110, which may be wired, wireless or combination thereof, asappropriate. The navigation map is implemented in a graph form.

The Navigation Map web server 100 is a RESTful API that provides secureaccess to the navigation map repository 103. All navigational maps builton a target device 106 are stored in database navigation map repository103.

The Navigation Map service 102 may reside on the connected device, asshown in FIG. 1. The Navigation Map service 102 may also reside in anexternal system like a remote server. This is shown in FIG. 1 a.

FIG. 1b describes the Navigation Map Service 102. The Navigation MapService 102 contains a search engine 150, a navigation engine 152, aremote command executor 154, a runtime screen monitor service 156 and aruntime data model extension 158. The search engine 150 uses keywordsprovided by the user and provides a list of screens which contain theprovided keywords. Based on the collected image and the screen layoutinformation, the Navigation Map Service 102 is able to highlight thescreen areas which contain the provided keywords.

Given a start screen and a destination screen, the navigation engine 152computes the path and navigates through the path directly on theconnected device. There are two modes of navigating: automatic mode andmanual mode. In automatic mode, the map building tool analyzes thecurrent screen and automatically tries to expand the navigational map byinvoking the screen elements using the remote command executor. Theremote command executor 154 listens to commands received from thenavigation map builder 105, for example, and executes it on theconnected device.

The commands are based on the navigation map. The navigation mapcontains what commands are needed to be performed for each step. Theremote command executer 154 executes the commands on the device to showthe user how the action is done. For example, for a “How do I turn onwifi”, the command could be in this form—tap at x,y on the screen, turnon switch or scroll on page downwards. The commands are used to invokeuser interface (UI) elements on the screen without user involvement.

The remote command executor 154 executes the received commands, such astapping on a specific co-ordinate on the device screen, scrollingthrough the device screen or activating specific hardware and softwarebuttons on the connected device. The runtime screen monitor service 156,if activated, watches the current device screen and matches the currentdevice screen with the prebuild navigation graph. The runtime data modelextension 158, if activated, expands the NM graph at the runtime withvertices and edges built with the screen which are not already presentin the graph. The NM map service 102 also synchronizes the local NMgraph on the connected device with the central NM graph stored on theremote server database 103, for example.

In manual mode, for each navigation step, the user is guided on whereand which action to take directly on the connected device. Inparticular, the user is instructed on which action to take (byhighlighting the UI element on the screen) and the user will take theaction. In this case the remote command executor 154 is not involved.

Referring back to FIGS. 1 and 1 a, the Navigation Map (NM) builder 105builds new device maps by scanning the target device 106, (which is asample connected device), and retrieving the structural layout of thetarget device 106. The process used by the NM builder 105 in creatingnew navigation maps is described in detail in FIGS. 5 and 6. The mapsbuilt by the NM builder 105 are then sent to the NM web server 100 to bestored in the device map repository 103.

The Simulator 104 utilizes a search engine that works in conjunctionwith the navigation maps and input keywords, to act as a devicesimulator. It downloads navigation maps for a specific device from theNM web server 100. The device navigation maps can also be utilized as aninteractive navigation system within a connected device, for example,connected device 107. This could be achieved by integrating theNavigation map service 102 with an application on the connected device107 or by using the NM service as a standalone service. The NM service102 downloads maps from the NM web server 100 and stores it in aninternal database 108 for offline navigation. If the NM service 102 isconfigured to expand on the NM graph during runtime, any dataaccumulated in this process is stored in the internal database 108 andsynchronized with the central repository 103.

The Navigation map builder 105, which is utilized to build the devicenavigational map on the target device 106, could either reside or beimplemented on a personal computer or a secure server. The applicationcould remotely scan the device by using a remote control connection orthe target device 106 could be connected to the computer by means of atethered connection or untethered connection such as wifi, Bluetooth® orthe like. This is described in more detail in FIG. 3. Alternatively, theNavigation map builder 105 could be installed within the target device106 to perform the same operation of traversing and scanning the entiredevice to collect data which could then be used to build the devicenavigation map. This is described in more detail in FIG. 2. In summary,there are 2 ways to get data: 1) offline mode, where scanning andcollected data are both hosted on the connected device; and 2) onlinemode, where scanning is on the connected device but the collected datais stored on a remote location.

FIG. 2 describes a system where the navigation map builder 202 is hostedon a remote machine which could be a personal computer or a secureserver. The NM builder 202 communicates with the NM service 204 over theair though an internet connection 210. In an implementation, theinternet connection 210 can be via wired connections. The NM service 204scans the entire connected device 203 and retrieves the device layout.The NM service 204 then sends the scanned device layout to the NMBuilder 202. A copy of this information is stored within the InternalDatabase 205. Using the data retrieved from the connected device 203 viathe NM service 204, the NM builder 202 builds out a navigational mapgraph as described in FIG. 4. The NM graph is forwarded to the NM webserver 200 and stored in the central data repository 201 for allnavigation maps.

FIG. 3 describes a system where the navigation map builder 303 residesand operates on a connected device 300 on which the navigation map isbuilt. The Navigation Map Builder 303 could reside within the NavigationMap service 302, which could be a part of an application 301 or astandalone service within the device 300. The NM builder 303 uses theprocess described in FIG. 5 to build a NM graph of the host connecteddevice 300 and stores it in the internal database 304. The NM graphbuilt on the device 300 is forwarded to the NM web server 305 to besynchronized with the central repository 306 for device navigation maps.

FIG. 4 gives an exemplary view of a device navigational map. TheNavigation Map is represented by a graph and the graph is defined as alist of vertices and a list of edges (each edge is a pair of vertices).In this context, the vertex encapsulates all the data for a particularscreen. Each vertex could be a screen or an application or an iconwithin the device. The vertices are connected together by the edges. Theedges define what action needs to be performed to navigate from onevertex to another. The navigational map as a whole provides a twodimensional view of the entire device software and information on how tonavigate to different areas within the connected device. It alsocontains additional information about the connected device such asdevice make, model, OS version, software version and the like.

FIGS. 5a-b elaborate a detailed call flow involved in creating a newdevice navigational map on a target device, (a sample connected device).The navigational map builder performs the following actions. Initially,a “Home” button tap command is sent to the target device [1] to ensurethat the NM graph is always built from a known starting point. A getcurrent screen layout command is sent to the connected device [2]. Oncea screen layout is received, a get current screen image command is sentto connected device [3]. Using the screen layout and screenshot, a newvertex is created and added to the navigational map graph [4]. Thiswould form the first vertex within the NM graph. A queue Q is created tocontain all vertices that need to be visited within the graph. A queue Qcontains the list of vertices which are not visited yet and isdynamically expanded while scanning the connected device. The scanningis done once a specific scanning deep/depth level is reached. This levelis provided as an input parameter to the algorithm. For instance, thehome screen represents level 0, the apps icons represents level 1, thesettings page represents level 2 and so on.

The newly created vertex from step 4 is added to Q [5]. The vertices tobe visited count is set to 1, and the current depth or visiting level isset to 1 [6]. The NM builder now checks if Q is empty [7]. If the Q isempty, the process is stopped and the building process is complete. Ifthe Q is not empty, the Q is checked to see if the current depth orvisiting level to be visited is less than the pre-defined maximum depthlevel to visit [8]. If not, the process is stopped and the buildingprocess is complete. A pre-defined maximum depth level could be set toensure that the NM graph is manageable so as to be useful. If thecurrent depth level is less than the maximum depth levels to visit, thena vertex V is de-queued from the Q [9]. The NM builder sends a requestto the connected device for the current screen layout [10]. A queryvertex is created with the screen layout [11]. A query vertex is atemporary vertex created from the current screen which is not attachedto the current graph and is used to match the current screen against thecurrent navigation map.

The NM builder then checks if the query vertex is the same as visitingvertex V [12], where a visiting vertex is the current vertex to beexamined by the algorithm. At each step, the algorithm tries to discoverthe other unvisited screens that are reachable directly from the screenrepresented by the visiting vertex. If it's not the same, the NM buildercalculates the shortest path from the home screen to the vertex V [13].It then sends a command to the connected device to navigate back tovertex V using shortest path calculated in step 13 [14]. If the queryvertex is equal to visiting vertex V, then a context menu command issent to the connected device [15]. This will open the context menu onthe connected device for the particular screen, which is one of theother unvisited screens.

Next, the NM builder will explore the new screen on the connected device[16]. The process involved in exploring a new screen is described indetail in FIG. 6. Once the new screen is explored, it is checked todetermine if there are more links to be visited from vertex V [17]. Ifyes, then a TAP command, (a TAP command is equivalent to pressing aspecific user element on the device screen (e.g. tap app icon)), is sentto the connected device at the position stored in the link [18]. Thedevice layout for a particular screen will contain information about alllinks and its co-ordinates within the screen. The TAP command isreceived by the NM service and executed on the device. The NM builderexplores the new screen opened by the tap action [19].

Once all the links within the screen are visited, a test is done tocheck if vertex V has scrollable elements on the screen [20]. If not,then the screen is marked as visited [23]. If there are scrollableelements within vertex V, then a SWIPE command is sent to the connecteddevice [21]. The swipe command could consist of Swipe UP, Swipe Down,Swipe Left and Swipe Right sub commands. The NM service performs theswipe actions on the connected device. The new screen opened on theconnected device is then explored by NM builder [22]. The visitingvertex V is then marked as Visited [23]. The NM builder then checks ifthe vertices on the current level is equal to 0 [24]. If yes, then thecurrent level is incremented by 1 [25]. The vertices on the currentlevel are set to the size of the queue Q [26]. Then the process islooped back to step 7. If the vertices on the current level is not equalto zero, then the process is automatically looped back to step 7 [27].

FIG. 6 elaborates the process of exploring a new screen on the device.For example, while on the home screen, if clicking a particularco-ordinate on the connected device opens a new screen, that new screenis completely explored before moving back to the home screen. To explorea new screen, the NM builder sends a command to the connected device toget the current screen layout [1]. Once the current screen layout isreceived, the NM builder requests a screenshot of the current screenfrom the device [2]. A query vertex is created based on the screenlayout and screenshot received from the connected device [3]. The NMbuilder then checks if the query vertex already exists in the NM graph[4]. The query vertex is matched with every other vertex within the NMgraph. The matching is done taking into account many parameters like anyvisible texts on the vertex screen, any hidden texts on the screen,control types (clickable links or icons) and their positions within ascreen, images and so on. If a matching vertex does not exist, then anew vertex V1 is created and added to the NM graph [5]. A new edge isadded between the visiting vertex V and new vertex V1. The edge tag isset to the action that was performed to navigate from vertex V to V1[6]. The action could be a tap, swipe or button action. Once the edge iscreated, a check is made to ensure the current vertex is marked asVISITED [9]. If a match is found in step 4, then a check is made toensure that an edge exists between V and current vertex [7]. If not, anew edge is added between vertex V and current vertex [8]. Once the edgeis created, a check is made to ensure the current vertex is marked asVISITED [9]. If an edge exists in step 7, a check is made to ensure thecurrent vertex is marked as VISITED [9]. If the current vertex is notmarked as visited, NM builder adds the current vertex to the visitingvertex queue Q [10]. It then sends a command to the connected device tonavigate back to visiting vertex V [11]. If the current vertex is markedas visited, then the command is directly sent to the connected device tonavigate back to visiting vertex V [11].

FIG. 7 gives a closer view of a target (sample connected) devicenavigational map. The map can be viewed in any layout type like a treelayout, a circular layout or a link log layout. FIG. 7 shows a devicenavigational map in a tree layout. At the top of the tree is node 0which is connected to multiple nodes using edges. In the sample, node 0contains the information about the home screen of a connected device.Performing an action on the home screen like tapping on specificco-ordinates or swiping from left to right will allow for navigation toother connected nodes. For example, pressing the menu button on theconnected device will allow navigation from the home screen to thesettings menu slide as shown in node 0.1, tapping on the calendar iconwill allow navigating to calendar application screen node 0.5, andtapping on the contacts icon will allow navigating to contactapplication screen node 0.4.

FIG. 8 shows the structure of the navigational map in a graph structure[800]. The graph consists of the following data: a list of all verticeswithin the graph [810], a list of all edges within the graph [820] anddevice information [830]. Device information contains detailedinformation about device hardware and software such as device make,model, operating system version, software version and firmware version.

A vertex is a node within the graph which represents the differentscreens within a device's user interface. A vertex might also representdifferent states of a single screen within a connected device as basedon specific configurations made on the connected device. For example, anetwork settings screen with mobile data enabled might be different fromone where mobile data is disabled. FIG. 9 shows a sample image of avertex within a navigational graph. This specific vertex has a uniqueidentifier 0 and represents the home screen of a connected device. Thisvertex also contains an image of the home screen in its default state.

FIG. 10 describes the structure of a vertex within a navigational graphin detail. A vertex contains the following information: a unique id1010, an image of the device screen currently in focus 1020, theapplication name 1030, which could also include the package name, andactivity name and screen links 1040. The screen links 1040 contain thefollowing information: a list of control buttons or actionable elementswithin the screen, link or index information, visible texts, invisibletexts, boundaries of screen link which include the exact co-ordinateswithin the device screen, control type which specifies if the screenlink is a button, check box or a list and information about thecharacteristics of the link like whether it can be enabled or disabled,checked or scrollable.

An edge is a directional link between two vertices. It containsinformation about how to navigate from one vertex to another and theaction that needs to be performed to navigate from one vertex toanother. FIG. 11 shows a sample edge between two vertices. The figureshows vertex with unique id 0 being connected bi-directionally to 5other vertices with unique ids 0.1 0.2 and so on. Hovering over on anedge reveals the area of the connected device where an action needs tobe taken to navigate from the source vertex to the destination vertex.As shown in this example, the edge 0-0.5 connects vertex 0 to vertex0.5. Tapping on the email icon within the vertex 0 will allow the systemto navigate from source vertex 0 to destination vertex 0.5. The edge0.5-0 connects vertex 5 back to vertex 0.

FIG. 12 describes the structure of an edge within the navigational map.Each edge consists of the following parameters. A unique identifier 1210which is used to identify each edge within the map, a source vertex id1220 which describes the originating vertex of the edge within a map, atarget vertex id 1230 which describes the destination vertex of the edgewithin a map and a tag 1240. A tag 1240 contains information on whataction needs to be taken to navigate from a source vertex to a targetvertex. A tag 1240 could be one or more of the following: tap tag, swipetag, home button tag, back button tag, menu button tag, pinch tag,multi-finger gesture tag or a scroll tag.

FIG. 13 shows a sample image of a device navigational map being utilizedas a simulator which can mimic the user interface, features andfunctionality of an actual connected device. Each of the vertices withinthe graph represents different screens on the device as well as itsvarious states. Since the map also contains information on how tonavigate from one screen to another and from one state to another state,the simulator can mimic the behavior of a physical connected device. Forexample, if a user taps on phone icon on the home screen, where homescreen is a vertex and the phone icon is one of the screen links withinthe vertex, the user will be presented with the phone application screenwhich is another vertex within the graph. The home screen and phoneapplication screen are connected by a unique edge which gets activatedby a tap action on the phone icon. Since all visible text on a screen isalso captured within the vertex, any component of the connected devicewhich has a text associated with it can be searched within thesimulator. For example, searching for text “Bluetooth” within thesimulator will retrieve all screens within the device navigational mapwhich contains the text Bluetooth.

FIG. 14 describes the use of a navigation map graph in an interactiveguidance system. For the purpose of illustration, the figure describesthe interaction between the following entities: Consumer 1410 is an enduser of a connected device 1430 who is interactively being guided on theconnected device 1430; Navigation map service 1420; and the connecteddevice 1430. When a consumer 1410 needs assistance in accessing specificsections of the connected device 1430 or configuring device settings,the consumer 1410 will provide query keywords using audio input, textinput or other input means, which is intercepted and processed by thenavigation map service 1420 [1]. The navigation map service 1420 willsearch for the keyword within all vertices of the navigation map whichhas been downloaded from NM server for the particular connected device.If a keyword match is found within the screens of vertices, a list ofall screens containing the keyword is presented to consumer 1410 [3].The consumer 1410 can choose the desired screen or settings page fromthe list presented [4]. The navigation map service 1420 will now assistconsumer 1410 in navigating to the chosen screen. The NM Service 1420will calculate the shortest path from the current screen on theconnected device 1430 to the target screen [5]. The path to navigatefrom one screen to another might comprise one or more edges. For eachedge on the navigation path, NM service will provide a visual guidanceon the device user interface and command the connected device 1430 toperform actions described within each edge tag [6]. Consider the exampleof a consumer requesting to be navigated to the browser settings screen.The shortest path calculated to navigate to the browser setting screenfrom the home screen is to tap on the browser and tap on the menu icon.The NM service will command the device 1430 to first navigate to thebrowser screen by performing a tap action on the browser link element,where the Tap action is an edge tag between the source vertex homescreen and the target vertex browser screen. Alternatively, the consumer1410 might be presented with visual or audio instructions and requestedto perform a tap action on the browser icon. Next, the NM service willcommand the connected device to navigate to a browser setting screen byautomatically performing the tap action on the menu icon or request theconsumer to perform the action.

In a use implementation, when Navigation Map Service 102 is enabled,Navigation Map Service 102 can record the user activity on the connecteddevice. The user activity can then be matched against the navigationmap. This matching can reveal, for example, how long the user has spenton a specific application, how long the user has spent on a specificscreen within an application and what kind of actions he/she has taking,(e.g., button clicks, input, turn on/off features, scrolling etc).

While detailed embodiments of the instant invention are disclosedherein, it is to be understood that the disclosed embodiments are merelyexemplary of the invention, which may be embodied in various forms.Therefore, specific functional and structural details disclosed hereinare not to be interpreted as limiting, but merely as a basis for theclaims and as a representation basis for teaching one skilled in thetechnology to variously employ the present invention in virtually anyappropriately detailed structure.

Although features and elements are described above in particularcombinations, each feature or element can be used alone without theother features and elements or in various combinations with or withoutother features and elements.

What is claimed is:
 1. A method for creating a navigational map for aconnected device, comprising: scanning the connected device to retrievestructural layout, hardware information and software information of theconnected device; generating vertices and edges from the scannedconnected device, wherein each vertex encapsulates data for a connecteddevice component and each edge defines actions needed to move between apair of vertices; building a navigational map from the generatedvertices and edges; and storing the navigational map in a database. 2.The method of claim 1, further comprising: receiving an inquiry from auser; providing a list of screens responsive to the inquiry; retrievingan applicable navigational map; computing a path between a start screenand a destination screen using the retrieved navigational map retrievedin response to selection of the destination screen; and navigating thepath on the connected device using the navigational map.
 3. The methodof claim 2, wherein navigating the path further comprises: executingcommands on the connected device to move along the path.
 4. The methodof claim 3, further comprising: monitoring a current screen against theretrieved navigational map; and matching the current screen with theretrieved navigational map.
 5. The method of claim 1, furthercomprising: modifying the retrieved navigational map with screens notpresent in the retrieved navigational map; and updating a navigationalmap in the database corresponding to the retrieved navigational map. 6.The method of claim 1, further comprising: setting a depth level for apredetermined set of connected device components, wherein scanning iscompleted upon reaching a designated depth level.
 7. The method of claim1, further comprising: creating a queue of unvisited vertices, whereinthe queue is updating during scanning of the connected device; for eachvertex: determining other unvisited vertices that can be reached;creating a query vertex for each unvisited vertex; determining if thequery vertex already exists in the navigational map; creating a new edgeif the query vertex does not exist; and decrementing the queue when allvertices for a depth level is complete.
 8. The method of claim 7,wherein all links and scrollable elements are checked to determineexistence of the other unvisited vertices.
 9. A system for creating anavigational map for a connected device, comprising: a database; and anavigation map builder, wherein when the navigation map builder isconnected to a connected device, the navigation map builder: scans theconnected device to retrieve structural layout, hardware information andsoftware information of the connected device; generates vertices andedges from the scanned connected device, wherein each vertexencapsulates data for a connected device component and each edge definesactions needed to move between a pair of vertices; builds a navigationalmap from the generated vertices and edges; and stores the navigationalmap in the database.
 10. The system of claim 9, further comprising: anavigation map service connected to the connected device, the navigationmap service further comprising a search engine, a navigation engine, anda remote command executor, wherein when the navigation map servicereceives an inquiry from a user: the search engine receives the inquiryand provides a list of screens responsive to the inquiry; the navigationmap service retrieves an applicable navigational map; the navigationengine computes a path between a start screen and a destination screenusing the retrieved navigational map retrieved in response to selectionof the destination screen; and the navigation map service navigates thepath on the connected device using the navigational map.
 11. The systemof claim 10, wherein the remote command executor executes commands onthe connected device to move along the path.
 12. The system of claim 11,wherein the navigation map service further comprises a screen monitor,the screen monitor monitoring a current screen against the retrievednavigational map and matches the current screen with the retrievednavigational map.
 13. The system of claim 9, wherein the navigation mapservice further comprises a navigational map extender, the navigationalmap extender modifying the retrieved navigational map with screens notpresent in the retrieved navigational map and updating a navigationalmap in the database corresponding to the retrieved navigational map. 14.The system of claim 9, wherein the navigation map builder sets a depthlevel for a predetermined set of connected device components, andwherein scanning is completed upon reaching a designated depth level.15. The system of claim 10, wherein the navigation map builder: createsa queue of unvisited vertices, wherein the queue is updating duringscanning of the connected device; for each vertex: determines otherunvisited vertices that can be reached; creates a query vertex for eachunvisited vertex; determines if the query vertex already exists in thenavigational map; creates a new edge if the query vertex does not exist;and decrements the queue when all vertices for a depth level iscomplete.
 16. The system of claim 15, wherein all links and scrollableelements are checked to determine existence of the other unvisitedvertices.